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ABSTRACT 


Th defens response to a Chemical and Biological 





attack would be importantly based on predicting the 
dispersion of a toxic cloud. Considering that an Unmanned 
Air Vehicle would provide the capability for embedding and 


positioning inertial and air data sensors geographically as 





required, real-time wind estimation can be performed for 


every actual position of the flying device in order to 





predict the plume moving direction. The efforts in this 





thesis concentrate on the demonstration and validation of 





procedures for obtaining Wind Estimation close to real-time 





and its instantaneous monitoring. Th presented work is 





based on a particular UAV platform available at the NPS 








Aeronautical Department and it aims to establish a general 
methodology, which may be used on other flying devices with 
Similar available sensors. An accurate estimation of real 


wind for a particular combat scenario will enable 








operational units to have a near real-time decision aid. 
This final result could be integrated into a Command and 
Control net, to assist in a focused way the response to a 
Chemical and Biological attack and to map the source or the 


region to be affected. 
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cs INTRODUCTION 


Chemical and biological (Chem/Bio) weapons have posed 
a defense response security concern for some time and have 


gained a renewed focus due to actual tactical scenario 





threats. In order to successfully respond to attacks by 


such weapons the dispersion of a toxic cloud is important 





to measure and predict. Work in this thesis supported a 


Chem/Bio response project, which was a joint effort between 





the NPS Aeronautics and Astronautics Department and 





Meteorology Department to demonstrate and validate a method 


for the synthesis of measurements and predictions to aid in 





the response to a chemical and biological attack. 





One of th key features of the Chem/Bio response 
project was the prediction of a toxic plume movement, which 
strongly depends on the actual wind velocity in the combat 
scenario. Using an Unmanned Air Vehicle (UAV) for 


geographically positioning inertial and air data sensors, 








obtained measurements and sensed data was used as the input 


for a Real-Time Wind Estimation solution. 








This thesis research concentrates on the demonstration 








and validation of procedures for obtaining Wind Estimation 





close to real-time and its instantaneous monitoring. The 


presented work is based on a particular UAV platform 





available at NPS Aeronautical Department and it aims to 
establish a general methodology, which may be used on other 


flying devices with similar available sensors. 





An accurate estimation of real-time wind for a 
particular combat scenario will enable Operational Units to 
have an important decision aid which can be later 


integrated into a Command and Control net to assist in a 


focused way the response to a Chem/Bio attack. Furthermore, 


this real wind estimation can be used to map the source of 








the plume as well as the region to be affected. 


A. OBJECTIVES 


The starting point for this thesis research is the 


identification and understanding of available data that 








will b generated on an UAV platform and that will be 








available on a ground station as it is transmitted via Data 





Link. 





This available data includes a Differential Global 














Position System (DGPS), an Inertial Measurement Unit (IMU), 








an Air Data System and a Data Link assembly; all of them 
embedded onboard the NPS FROG UAV. All the necessary 
background to understand and identify the generation of the 


inputs that will be later used for Wind Estimation is 

















included in Chapter Two (II.). It also includes a brief 

















description of the UAV and the Data Link system used. 




















Chapter Three ( -) will focus on the development of 


the proposed Wind Estimation Model. This work used SIMULINK 








for solving necessary applied mathematics in the Wind 


Estimation calculation and xPC Target software package to 





carry out th required real-tim signal processing and 


results presentation. 








Chapter Four (IV.) will cover the flight test setup 





and data acquisition that lead to the model validation. 








Flight test results will be discussed and the model will be 


evaluated against the meteorological wind measurements. 





Finally, on Chapter Five (V.) recommendations and 





conclusions will be presented. 


II. BACKGROUND 


A. THE UAV PLATFORM (NPS FROG) 


The FROG UAV is a small high wing monoplane used for 











Digital Control System research by the Department of 


Aeronautics of the Naval Postgraduate School. The airplane 











is manufactured by BAI Aerosystems Inc., as the “BAI TERN” 
(Tactically Expendable Remote Navigator), and was formerly 


designated the FOG-R by the U.S. Army. In the FOG-R 





configuration the airplane has been flown non-line-of-sight 





using a fiber optic Data Link for command uplink and video 
downlink. The wing is fitted with flaps that can be trimmed 


to provide slow flight speeds for surveillance and extended 





to facilitate tight landings. 





Figure II.1 FROG UAV Three View Drawing. 


FROG is equipped with conventional elevator, rudder, 
ailerons and flaps. Small servomotors, designed for use in 


radio-controlled airplanes, actuate the control surfaces. 
3 


This UAV was designed to carry up to twenty-two pounds 





of payload for periods of up to four hours. It is actually 











equipped with a Model BA64 6.4 cubic inch, horizontally 





opposed, piston engine, manufactured by Brinson Aircraft 





Company. The 2-cylinder engine developed 9.3 Hp and is 
equipped with a two bladed propeller mounted in a tractor 


orientation in a nacelle atop the wing, as depicted in 











Figure (I1I.2). The FROG has fixed tricycle landing gear 








with a steer able nose wheel. The empennage is connected to 








the body of the airplane by a 1.75 inch diameter aluminum 


tube. 





Figure II.2 FROG UAV Engine Configuration. 


FROG is currently in use as a test bed for airborne 


sensor systems and advance control projects for the 





Aeronautics and Astronautics Department at NPS. In the 





past, the NPS’s FROG had been configured with a variety of 
sensors including an onboard autopilot, various inertial 
measurement units, GPS receivers, an instrumented nose boom 


and a digital camera. 





























The FROG’s significant physical characteristics 
presented in Table «ths 
PARAMETER MEASUREMENT 
Length 8.125 Ft 
Height Le S £E 
Weight 67.7 lbs 





Power Plant 9.3 Hp / 2 Cycle 





Wing Airfoil NACA 2415 





Horizontal Stabilizer Airfoil NACA 0006 (Approx.) 














Wing Span (b) 126.5 in 

Tail Span (b,) 39375: Ahn 

Vertical Tail Span (b,) 15/0: ain 
Aspect Ratio (AR) 6.32 














Table II.1 FROG UAV Physical Characteristics 


More details on the FROG characteristics and 


engine are documented in Appendix A [Ref. 1]. 


eS ae te oh eh oe gl Br sete SS 





Figure II.3 


FROG UAV Actual Configuration 


ake 


its 


B. DIFFERENTIAL GLOBAL POSITIONING SYSTEM (DGPS) 


The GPS receiver used on the FROG is Trimble Ag132 





DGPS shown in Figure (11.4). The Agl32 DGPS is a 12 channel 











L-band differential correction receiver that provides sub- 





meter accuracy. It combines a GPS receiver, a beacon 
differential receiver, and a satellite differential 
receiver in the same housing. These receivers use a 





combined antenna with a single antenna cable. The Agl132 is 
configured with two programmable RS-232 serial ports and 


outputs GPS data at 1, 5 or 10 Hz with latency of 10 msec 











in RS-232 serial ASC format at baud rates up to 38,400 








bps. All outputs conform to the National Marine Electronics 


Association (NMFA)-0183 data protocol. 





Figure II.4 DGPS Trimble Ag132 Main Components and 
Mounting Locations. 


Among the various sentences in the GPS data stream 











shown in Table .2, only information in the SGPGGA (GGA) 





and the SGPRMC (RMC) sentences is relevant to this 


application. 


MESSAGE CONTENTS 








position and fix related data. 





ition fix, time of position fix and status. 














PS position fix mode, SVs used for navigation and 
DOP values. 


Pseudorange Noise Statistics. 








umber of SVs visible, PRN numbers, elevation, 
uth and SNR values. 
Signal strength, signal-to-noise ratio, beacon 
frequency and beacon bit rate. 

time, status, latitude, longitude, speed over 
ground (SOG), date and magnetic variation of the 
ition fix. 


Actual track made good and speed over ground. 


UTC time, day, month, year, local zone number and 
local zone minutes. 

Beacon channel strength, channel SNR, channel 
frequency, channel bit rate, channel number, 
channel tracking status, RTCM source and channel 
performance indicator. 
Time, event number, and event line state for time- 
tagging change of state on a event input line. 


PTNL, GGK Time, Position, Position Type and DOP Values. 


PTNLI Receiver machine ID, product ID, major and minor 
Shoo ecg release numbers and firmware release date. 


Reference Station Number ID and the contents of 
PTNLSM the Special Message included in valid RTCM Type 16 
records. 











































































































Table II.2 DGPS Trimble Ag132 Messages 
Cc. INERTIAL MEASUREMENT UNIT (IMU) 
1. IMU Overview 
The Inertial Measurement Unit (IMU) that was built for 








the FROG to be used for this research work consists of four 
separate sensors and two microprocessors that are used to 


integrate and transmit sensor measurements. The sensors 








consist of the Trimble Ag132 DGPS, an Air Data assembly, a 





Microstrain 3DM accelerometer and magnetometer, and a 








Systrom Donner AQRS 104 rate gyros set. The microprocessor 








units are Tattletale8 Data Logger from Onset Corporation. 


The two microprocessors are programmed in Tattletale C (a 





variation of ANSI standard C) and control the timing, 


measurement and transmission of all sensors. The combined 





sensor output provides measurements of the complete state 





vector with the exception of heading angle yw, which can be 


computed from the other components of the state vector. 

















Table (CEh*.:3') shows the complet measurement values, 





associated sensors and the data rate at which the 


measurements are available. 









































































































































STATE VECTOR NOTATION | RATE | SENSOR NOTES 
Roll Rate 5) 40 Hz | AORS 104 4.096 Volt A to D sample 
Pitch Rate q 40 Hz | AORS 104 4.096 Volt to D sample 
Yaw Rate Lr 40 Hz | AORS 104 4.096 Volt A to D sample 
Temperature Temp 40 Hz OAT 4.096 Volt A to D sample 
Alpha a 20 Hz | AORS 104 4.096 Volt A to D sample 
Beta Bp 20 Hz | AORS 104 4.096 Volt A to D sample 
Airspeed Vair 40 Hz | Air Data 4.096 Volt A to D sample 
Accel. X component Ax 20 Hz 3D RS-232 9,600 baud 
Accel. Y component Ay 20 Hz 3D RS-232 9,600 baud 
Accel. Z component Az 20 Hz 3D RS-232 9,600 baud 
Mag. Vect. X comp. Ax 20 Hz 3D RS-232 9,600 baud 
Mag. Vect. Y comp. Hy 20 Hz 3D RS-232 9,600 baud 
Mag. Vect. Z comp. Az 20 Hz 3D RS-232 9,600 baud 
GPS Time t 10 Hz | DGPS RS-232 38,400 baud 
GPS Latitude Lat 10 Hz DGPS RS-232 38,400 baud 
GPS Longitude Long 10 Hz | DGPS RS-232 38,400 baud 
GPS Altitude Alt 10 Hz | DGPS RS-232 38,400 baud 
GPS Ground Speed Knt GrndSpd 10 Hz | DGPS RS-232 38,400 baud 
GPS Ground Track Deg GrndTrk 10 Hz DGPS RS-232 38,400 baud 
GPS Mag.Var.Deg MagVar 10 Hz | DGPS RS-232 38,400 baud 
Table II.3 IMU State Vector Components 





2. IMU Sensors Summary 


Sensor data rate is an important element when handling 





data obtained by different components. Data rates of 20 Hz 
for the Euler Angles rates (p, gq, & r) are known to be 
acceptable. Realistically a data rate of 30 to 40 Hz is 


required for the optimal digital signal processing. Each 





sensor has its own inherent limitations that restrict the 


maximum allowable data rate. Measurements from each sensor 





are taken at various data rates and merged together in 
order to achieve a high data rate yet maintain an easily 


decoded and error free data stream. 


Frog IMU Architecture 


GPS 10 Hz Pitot Static 40 Hz 
(time, lat, long, alt, (A/S, T, P) 


speed, heading, etc) Ato D Samples 
RS-232 38,400 bps 
Tattletale 8 Rate Gyros 40 Hz 


Digital 
57.600 bps Ato D Samples 
(p. q. 1) 


\ 3DM Accel 20 Hz 
aes \ RS-232 9,600 bps 
( 





Sensors 20 Hz 38,400 bps Ax, Ay, Az, Hx, Hy, Hz) 


(co, B, future sensors) 
AtoD Samples 


To Modem System Timing 
Figure II.5 IMU Architecture and Data Rates 
a. Onset Tattletale 8 Microprocessor 
The Tattletales Microprocessor from Onset 


Computer Corporation is designed to be a data logger that 
can either be programmed in Tx Basic or C Programming. The 


Tattletale8 has a Motorola 68332 microprocessor, 8 channels 








to make analog to digital conversion (A to D) samples using 
9 


a 4.096 volt reference, two RS-232 serial communications 
ports, a system clock adjustable from 160 KHz to 16 MHz, 
and 15 digital (0 to 5 volts) lines that can be used to 





transmit serial data at up to 500 Kbps. 











As seen on previous Figure (E265) > two 





Tattletale8 are used to process the data and measurements 





made by the IMU. One Tattletale8 is dedicated to the 





processing of serial GPS data and taking A to D samples 
from the Air Data system. The second Tattletale8 takes the 


serial output of the 3DM, A to D samples for the IMU 








sensors (Rate Gyros and Air Speed), and controls all of the 





measurement and transmission timing. The GPS Tattletales 


transmits its data to the 3DM Tattletale8 via the digital 





lines. 


The communication link between the UAV and the 





ground station computer is implemented with wireless 
modems. Each modem uses frequency hopping spread spectrum 
technology and has a power output of 1/3 Watts. They are 
capable of communicating over a line of sight with range of 
up to 20 miles, and to support data transmission at baud 


rates from 1200 bps to 115.2 Kbps. The ground station 





computer performs the real-time data logging and processes 


the transmitted data according to the Wind Estimation 





algorithm. 





Figure II.6 Data Link Modems 
10 


data at l, 


format at baud rates up to 38,400 bps. 


data 





to the National 


b. 


The Trimble Ag132 GPS 





protocol used by GPS 
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Marine Electronics Association 
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the 


at a baud rate of 38,400 bps. 
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SGPGGA 
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(NMEA) GPS 


transmit data. 
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information not included in final IMU data stream. 





SGPGGA Sentence: 


Global Positioning System Fix Data 






















































































EXAMPLE: SGPGGA, 001218.80, 3635.761652, N, 12152.607700, 2-8. y> Lesley 
15.14, M, -27.47, M, 5.4, 0565*45 
Field | Description Data Notes 
1 UTC of Position Gorstacees- || tee ee Oey eee 
UTC 

2 Latitude 3635.761652 | LAT 36° 35.761652’ 

3 IN| oie 1S N North Latitude 

4 Longitude 12152.60770 LONG 121° 52.6077’ 

5 la, OI WW W West Longitude 

6 eer eee 2 DEPS Mode 
Number of satellites in use 08 8 Sats. in use 

8 Horizontal dilution of position itil HDOL sie 

9 Altitude +/- mean sea level (geoid) 15.14 oa ca ee 

10 Meters (Antenna height unit) M eters 
Geoidal separation (Deis tare between 

il WGS-84 earth ellipsoid and mean sea | -27.47 a2 47 Isilon 
level - = geoid is below ellipsoid) 

2 Meters (Units of Geoidal sep.) M Meters 

13 Age in seconds since last update from 5.4 PAyeo ee ee abel 
Diff. reference station 

14 Diff. reference station ID# 0565 Station # 

LS) Checksum eaN'5) Checksum 

















Table II.4 
ils]? 


SGPGGA Sentence Structure 

















































































































S$GPRMC Sentence: Recommended Min. Spec. GPS/TRANSIT Data 
EXAMPLE: SGPRMC, 001218, A, 3635.761652, N, 12152.607700, W, 000.00, 0.0, 
170401, 15.3, E, D*03 
Field Description Data Notes 
i UTC of position fix 001218 ae St ees 
2 Data status (V navigation receiver K Receiver Status 
warning) Valid 
3 Latitude of fix 3635. 761652 || mwAW 36° 35. 761652" 
4 NI OaEES N North Latitude 
5 Longitude of fix IZALS2, 60770 || HONE W210" 52.6077" 
6 E or W W West Longitude 
Speed over ground in Knots (0-3 0.0 Knots ground 
7 ‘ 000.00 
decimal places) speed 
8 True Ground Track in degrees True 0.0 0.0° ground track 
9 UTC date 170401 mee 7, ZOOL 
10 agnetic Variation degrees (Easterly 15.3 agnetic Variation 
Var. subtracts from true course) ° Anoeec hs 
11 E or W E East 
12 Checksum D*03 Checksum 
Table II.5 S$GPRMC Sentence Structure 
c. DGPS Trimble Ag132 Data Conversion 
The SGPGGA and SGPRMC sentences combine 161 ASC 
text characters. This data is received approximately 10 





times per second and would take up about one third of the 


available bandwidth of the final IMU data stream at 38,400 











bes, if all of the text values were transmitted. Therefore, 
it is necessary to sort out and transmit only the 
information required by the application. Transmitting the 





critical data in a binary format 
stream 
data package includes 





start of the GPS message, 


size 


series of 8 bit bytes. 


the 


Values that range between O and 255 ar 


to 31 bytes. 





Data is 


data stream must 





to be reduced to 29 bytes of binary data. 





allows the total data 


Each GPS 





a two-byt 


header to indicate the 


bringing the total GPS packet 


transmitted 


The serial 


in a binary format as a 


driver that is receiving 





decode 


12 


it before it can be used. 





represented by a 





Single byte of data and no conversion is necessary. Values 





that range between 0 and 65535 ar represented by a two 
byte integer with the most significant byte (MSB) 
transmitted first, followed by the least significant byte 
(LSB). To decode the two-byte integer the MSB must be 





multiplied by the placeholder value of 256 (2°) and added to 





the LSB. When decoding entire bytes the placeholder values 


inerease: by factors of 2” (ux 2", 2°, 2°). 2, Ste). This ts 





a simple conversion that can be implemented in most 











programming languages. It is worth noting, however, that 





this only works for unsigned values. If signed values are 





used, the bits of the MSB must be shifted by the 





appropriate amount to preserv th integrity of whatever 
signing convention is used. Numbers greater than 65535 are 


represented by a four-byte long integer with the MSB 








transmitted first. The four byte sequence is decoded using 





the following equation: long integer = 274xBytel + 2*°xByte2 























+ 2°xByte3 + 2°xByte4. Table (II.6) shows the format of the 





DGPS data and method required to convert the data to a 








useable number format. 





DGPS Data Package Format 




































































EXAMPLE: SGPGGA, 001218.80, 3635.761652, N, 12152.607700, W, 2, 08, 1.1, 
15.14, M, -27.47, M, 5.4,0565*45 
SGPRMC, 001218, A, 3635.761652, N, 12152.607700, W, 000.00, 0.0, 
170401, 15.3, E ,D*03 
Data Description Notation Bytes | Text Binary | Decoding Method 
GPS Data Package Header] GPS Header 2 sae Hex values 
Hours (00 — 23) timeHH 1 00 00 /A 
Minutes (00 - 59) timeMM 1 12 AEB. /A 
Seconds (00 - 59) timess 1 18 18 /A 
Decimal Seconds (0 —- 9)] timeDecSS 1 8 08 /A 
Degrees LAT (00 - 90) latDeg 1 36 36 /A 
Minutes LAT (00 - 60) latMin 1 35 35 /A 
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DGPS Data Package Format 













































































EXAMPLE: SGPGGA, 001218.80, 3635.761652, N, 12152.607700, W, 2, 08, 1.1, 
15.14, M, -27.47, M, 5.4,0565*45 
SGPRMC, 001218, A, 3635.761652, N, 12152.607700, W, 000.00, 0.0, 
170401, 15.3, E ,D*03 
Data Description Notation Bytes | Text Binary | Decoding Method 
D 1 1 Mi t LAT re MSB 1" 
ieee a ee . | latDecMin 4 761652 isq | 2o{xBytel+2"*xByte2+ 
ecimal places a 2°xByte3+2°xByte4 
Degrees LONG (00 - 180)] longDeg 1 121 121 /A 
Minutes LONG (00 - 60) longMin 1 52 52 /A 
Decimal Minut LONG 45 SB 1" 
hasges ; coca longDecMin 4 607700 2**xBytel+2°°xByte2+ 
(0 -7 decimal places) 69 8 0 
212 2°xByte3+2° xByte4 
DGPS status diffGPs 1 2 02 /A 
; 00 SB 1°° LSB 2°¢ 
Altitude in meters altMeters 2 +5 15 22 xBytel+2°xByte2 
Altitude in tenths of slenechKS 1 14 14 /R 
meters 
00 SB 1°° LSB 2°¢ 
Groundspeed in knots grndSpeed 2 000 00 2° xBytel+2°xByte2 
Groundspeed in tenths grndSpeedbe 1 00 00 /R 
of knots cimal 
Ground track in degrees i ee > 0 00 SB 15° LSB 274 
(0-359) g 00 2°xBytel+2°xByte2 
Ground track in tenths grndirackDe 1 0 00 JB 
of degrees cimal 
Magnetic variation in 00 SB 1°* LSB 2"4 
Vv 2 1 
degrees eae 2 15 2°xBytel+2°xByte2 
Magnetic variation in 
VarD i A 
tenths of degrees caster ace a 2 / 























Table II.6 


d. 


At 10 Hz the 


DGPS Binary 








SGPRMC sentences 





ASC 








text data 





second without any dropouts on lost sample times. 


V 


is reli 





DGPS Time Issues 


ry 100 ms. 
ably 


For 


the 





received at 


DGPS 
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Data Package Format 


DGPS should transmit the SGPGGA and 


signal the 
samples per 


The exact 


timing of the arrival of the GPS data has a huge amount of 


variability. 





particular sample 


as late as 100 





creates 


On average, 


great problems 


, however, 


ms (i.e. 


data is received 


A 





very 100 ms. 


may arrive early or it may be 


200 ms 
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when regularly 


between 


samp 


samples). This 


led inputs are 








required. When the DGPS data does not arrive in time, the 





DGPS parsing routine waits for all of the data to arrive. 














Therefore, it is important that critical timing of 





measurements not to be based on or delayed by the arrival 





of the DGPS signal. Specific programming implementation 


regarding this problem must be addressed. 


e. 3DM Accelerometer and Magnetometer 








The 3DM module has an orthogonal array of DC 


accelerometers and magnetometers that measure all three 








components of the local acceleration and magnetic vectors. 
The unit is capable of transmitting computed roll, pitch, 


and yaw angles or raw acceleration and magnetic vectors. 





The 3DM uses the Earth’s gravity vector to compute the 


orientation of the sensor in pitch and roll direction. 





Using the magnetic vector and the pitch and roll angles, 








the 3DM can compute the yaw angle and therefore is able to 
determine all three Euler Angles. This method works well 
when the unit is in a static position; however, it will not 
work during accelerated flight onboard the UAV. When the 


UAV is in maneuvering flight (Ex: 60° AOB level turn at 2 











Gs) the unit will incorrectly measure the Earth’s gravity 
vector and consequently generat rroneous Euler angle 
measurements. Therefore, only the raw acceleration and 








magnetic vectors are output from the 3DM and valid results 





for Wind Estimation are only expected for a close to 





straight and level flight condition. 
The 3DM transmits RS-232 serial data at 9,600 








bes. The device can be put into one of two communication 





modes: polled or continuous. When the device is in 


continuous mode it sends packets of data to the computer 





continuously. In polled mode the unit only sends data if a 
15 





controlling computer prompts it. This is a more robust 


communications mode that requires less error checking. The 








polled mode is normally selected by sending the 3DM the 




















ASC character “t”. The 3DM installed in the Frog IMU, 





however, has a special EEPROM that allows only the polled 


mode. This was done to solve a problem with the device 








unpredictable switching communication modes. Thus, the 3DM 
can only be operated in the polled mode. 


When operating in polled mode it is necessary to 








send 3DM a specific one-byte command word before it will 





transmit its data. To receive the complete acceleration and 





magnetic vectors the binary value 10010000 (decimal number 





144) must be sent to 3DM. After receiving the appropriate 





command word, 3DM will transmit the data shown in Table 











( .7). This data is stored in a buffer in the Tattletales 











microprocessor and is transmitted at the appropriate time. 


The 3DM is polled and the sensor’s data is updated at a 





rate of 20 Hz. The remaining parameters of the IMU data 


package are measured at 40 Hz. 





To simplify the decoding of the IMU data a 











standard IMU package is transmitted at 40 Hz. The 20 Hz 3DM 


data is only updated every other frame even though the 12 





bytes of data is transmitted every single frame. A close 








examination of the 3DM output will reveal that the data 
occurs in repeated pairs. This may create some problems if 


the acceleration or magnetic data needs to be analyzed in 





the frequency domain. The data is transmitted MSB first and 


LSB second for each measured value. The bytes can be 











decoded as Value = 2°xBytel + 2°xByte2. Table (II.7) shows 








the order of data. 
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Data Description 
Diagnoseue BYES Ox4lh if Valid; Ox6Xh if error 
(“X” is an error code) 
H xm X Axis Magnetometer Data MSB 
Hy-1 X Axis Magnetometer Data LSB 
Hy-m Y Axis Magnetometer Data MSB 
Hy-1 Y Axis Magnetometer Data LSB 
Hom Z Axis Magnetometer Data MSB 
He-1 Z Axis Magnetometer Data LSB 
Ay-mn X Axis Accelerometer Data MSB 
Ay-1 X Axis Accelerometer Data LSB 
Ay-in Y Axis Accelerometer Data MSB 
Ay-1 Y Axis Accelerometer Data LSB 
Ag-m Z Axis Accelerometer Data MSB 
Ag-1 Z Axis Accelerometer Data LSB 
Table II.7 3DM Magnetometer and Accelerometer Data 
Format 
£.; AORS 104 Rate Gyros 
The Systrom Donner AQRS 104 rate gyros measure 





the angle rates of change (p, q, & r) about 


axis. The angle rates are measured by an Anal 








converter sampled from the Tattletales. 








only require an A to D_ sample, the 


Since 





og to 


the Body-Fixed 





Digital 





measurements 


only timing issue 





involved in determining the maximum sample rate is the time 





required for the Tattletale8 to make an A to D 





sample. 


Therefore the maximum sample rate is only limited by the 





rate at which the Tattletale8 can make A to 





transmit them to the modem. Current software is 





D samples and 


set to 





sample at 40 Hz. The thr sensors are actually wired to 


the Tattletale8 in the order (p, fr, & 


ula 


Q)r 


so the samples 





have been reversed in software to provide the conventional 





order (p, g, & r) in the output data stream. 


g. IMU Data Format 


In order to distinguish each package of data a 








two-byt header is added to the beginning of each data 











package as shown on Table (II.8): 








Data Header Formats 



















































































Header Header Data 
(Hex) (Decimal) Date type Size oo 
FF FF 255 255 IMU TT A to D Data 28 Bytes MSB, LSB 
238 238 GPS Data 29 Bytes MSB, LSB 
DD DD 22M 22.7. GPS TT A to D Data 16 Bytes MSB, LSB 
Table II.8 IMU Data Headers 
D. AIR DATA 


1. Air Speed 


Two basic pressures are used for measurement of 








airspeed, static and total pressure. The static pressure is 


the atmospheric pressure at the flight level of the 














aircraft, while the total pressure is the sum of the static 











and the impact pressure, which is the pressure developed by 


the forward speed of the aircraft. The relation of the 








thr pressures can thus b xpressed by the following 





equation: 


P= Pt, (1) 


Where pe is the total pressure, p is the static 


pressure, and q. the impact pressure. 
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In incompressible flow, the pressure developed by the 


forward motion of a body is called the dynamic pressure gq, 





which is related to the true airspeed V by the equation: 
2 
q=—pv (2) 


From Equation (2), o is the density of the air and V 





is the speed of the aircraft relative to the air. 





For compressible flow, the measured impact pressure qe 


is higher than the dynamic pressure and the effects of 





compressibility must be taken into account. Since the FROG 
operates in the low subsonic range, compressibility effects 
are ignored. 


The airspeed of the FROG is computed based on dynamic 





pressure measurement using a pitot-static probe mounted at 





a wingtip and pressure transducers. The dynamic pressure is 





“fed” into a pressure transducer that in turn converts it 


to the analog voltage signal. With proper calibration and 








application of Equation (2), the airspeed of the UAV can be 
computed. 


The pitot-static probe is a straight 26 inches long 





conventional type with four static pressure sensing ports 








located 1.125 inches aft of the total pressure port. 





Th pressur transducer used is a 0-4 inches’ H20 
differential pressure transducer that gives an output 


signal of 0 to 5 volts. 
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Figure II.7 Pitot-Static Probe Layout 





Figure II.8 Pressure Transducer 





Figure II.9 Pitot-Static Probe Mounted on FROG 
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2. Angle of Attack and Sideslip Angle Sensor 


Angle of Attack (Alpha, a, AOA) is defined as the 








angle between the relative wind in the plane of symmetry 


and the longitudinal axis of the aircraft. Sideslip Angle 








(Beta, $8) is defined as the angle between the wind vector 











and the plane of symmetry. Figure (II.9) illustrate these 





definitions: 








Figure II.10 a and B Definition 


Wind vanes mounted on potentiometers are used to 
measure a and. 6B Note that the 6 vane actually measures 


“flank angle of attack” but since a is small, true 6B can be 








approximated by “flank angle of attack”. 





The vane-potentiometer assembly is mounted on a probe 
that is similar to the pitot-static probe at the wing tip. 
The wind vanes are attached to the shaft of the 


potentiometer. As the UAV pitches and/or yaws, the vanes 





rotate and that causes the shaft to rotate. The rotation of 


the shafts changes the resistance of the potentiometers and 
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an analog output voltage signal is produced. With proper 





calibration, the a and 6 angles of the FROG are obtained. 





Figure II.11 a and B Vanes Mounted on Potentiometers 


Further details about air data capture, calibration 

















and processing can be found in Chapter three ( -) and 
[Ref. 2]. 
E. COORDINATE SYSTEMS 


To develop the relationship between the GPS and the 








IMU that is needed for attempting a Wind Estimation 
solution, an understanding of coordinate systems involved 
is essential. 


Four different coordinate systems are used in this 





thesis: 
° True Inertial Coordinate System {TI} 
° Local Tangent Plane Coordinate System {LTP} 
° Body-Fixed Coordinate System {b} 
° Wind or Flight Path Coordinate System {w} 


For the purposes of this thesis, the rotation of the 
earth and its associated Coriolis' forces can be ignored 
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and the Local Tangent Plane Coordinate System can _ be 





considered to be a True Inertial Coordinate System. Further 








information about Coordinate Systems can be found in [Ref. 


3:] % 


1. True Inertial Coordinate System {1} 





The True Inertial Coordinate System is a eset of 








mutually perpendicular axes that neither accelerate nor 





rotate with respect to some fixed point in space. Newton 


assumed there was a reference frame whose absolute motion 








was zero, fixed relative to the stars, and it is in this 


reference fram wher Newton's laws are valid. However, 





Newton's laws of motion can also be applied to any 
reference frame as long as the proper coordinate 


transformations are used. 


2. Local Tangent Plane Coordinate System {LTP} 


This coordinate system is defined by extending a ray 
from the center of the earth to its surface. A plane is 


attached tangent to the point of intersection of the ray 








with the EFarth's surface and this point becomes the origin 
of the system. While it is somewhat arbitrary, for our 
purposes it is defined the positive x-axis direction as 
pointing true east, the positive y-axis direction as 


pointing true north, and the positive z-axis direction as 





pointing up (away from the center of the earth). This is 











depicted in Figure (11.12). 
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Greenwich 
Meridian 














Equator Line 


Figure II.12 Local Tangent Plane Coordinate System 


3. Body-Fixed Coordinate System {b} 





The Body-Fixed Coordinate System is a right hand 


orthogonal system with the origin at the center of gravity 











of the air vehicl The positive x-axis direction points 
toward the nos The positive y-axis direction points out 
the right wing and the positive z-axis direction points 





Th 





towards the bottom of the air vehicl velocity of the 





air vehicle with respect to the Inertial Coordinate System, 


resolved along the x, y, and z axes of the Body-Fixed 
Coordinate System, are termed u, v, and w, respectively. 
The angular rate of rotation of the air vehicle with 





resolved in the 





respect to the Inertial Coordinate System, 





Body-Fixed Coordinate System, are called p, gq, and r, 
respectively. Positive values for angular rates in the 
Body-Fixed frame are shown in Figure (11.12). 
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Figure II.13 Body Frame Angular Rates Definition 


4. Wind or Flight Path Coordinate System {w} 


The Wind Coordinate System is also a right hand 


orthogonal system with its origin at the center of gravity 


of the air vehicle. The x-axis is aligned with the velocity 





vector of the air vehicle. The orientation of the Wind 


Coordinate System with respect to the Body-Fixed Coordinate 


System is defined in terms of the angles a and £8. The 


equations for a and 6 are given below: 
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BODY 
Z-AXIS X-AXIS 


Figure I1I.14 Wind Coordinate System Definition 


5 Coordinate Transformations 





In order to use the coordinate systems mentioned 





above, one must be able to transform between them freely. 


For this thesis two transformations are going to be used: 
a. Body to Inertial {b} to {I} 


The Euler Angles @, @ and w, named roll, pitch, 





and yaw are defined in order to express the orientation of 





the Body-Fixed Coordinate System with respect to the 








Inertial Coordinate System. For the purposes of this 
thesis, a 3-2-1 Euler angle transformation will be used. 


The 3-2-1 transformation is given without an explanation 





but a good development can be found in [Ref. 3 and 4]. 





Nature of the angular rotation is more apparent when the 


transformation is expressed as the product of three 





rotation matrices. In the case of a B52 1. rotation 








sequence, the thr matrices in Equation (5) correspond to 
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rotations about the yaw, pitch, and roll axes of the air 


vehicle. 
cos¥ sin¥Y 0/|cos@ 0 -sin@||1 0 0 
“vy =|-sin¥Y cos¥Y 0 o 1 0 0 cos¢@ sin@g|’v 
0 0 1/|sin@ 0 cos@ ||0 -sing cos@ 
(5) 


Of course, the three matrices can be multiplied 


out for an analytic result contained in a single matrix: 


cos@cos¥ -cos@¢@sin’+singsin@cos¥Y singsin¥Y + cos ¢sin Od cos VY 
iv =|cos@sin¥ cosgcos¥+singsin@sin¥ singcos¥ + cosgsin@sin¥Y|>V 


—sindg sin ¢@ cos 0 cos @ cos @ 


(6) 





Where 7?V is a free vector resolved in {I} and *vV 


is the same vector resolved in {b}. The inverse is also 








defined, Since the transformation is orthonormal. The 
inverse is the transpose of the rotation matrix shown in 


Equation (6). 





As previously mentioned, the IMU used on the FROG 


for this thesis is equipped with rate gyros that provide 





the angular velocity components in the Body Coordinate 
System (p, gq and r). The body reference frame’s angular 


rate can be related to the change of Euler Angles by a 


transformation matrix [Ref.4]. This is given by: 
¢ 1 singtan@ cos@tand||p 
6; =1|0 cos @ —sing q| (7) 
yy 0 singsec@ cos¢@secO@||r 
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b. Wind to Body {w} to {b} 





The angles a and £6 define the orientation of the 
Wind Coordinate System with respect to the Body-Fixed 
Coordinate System, therefore a transformation matrix can be 
obtained that relates a free vector resolved in {w} to the 
same vector resolved in {b}. The transformation is 


expressed as: 


cosa@cos # -cosa@sinf# -sina 
*V = sin £8 cos B 0 "V (8) 
sinacos f -sina@sinf cosa 


Where °V is a free vector resolved in {b} and "V 


is the same vector resolved in {w}. 





F. WIND ESTIMATION THEORY 


As stated in the previous point (E.), for this thesis 


Local Tangent Plane Coordinate System {LTP} is considered 











to be True Inertial Coordinate System {I}, therefore th 








Wind Estimation can be obtained by solving the following 


equation: 
i _ i i 
Vv, 77 Via aa wRV, (9) 
The vector ‘“V, stands for “wind velocity in the 


inertial frame” which is actually the True Wind that needs 





to be estimated. 


The vector Vis stands for “velocity of the body with 





respect to the inertial frame solved in the inertial 





frame”. Vee is given directly by the DGPS and for Wind 


Estimation purposes only components of the x-axis and y- 
axis are considered. 
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The vector Vv, Stands for “velocity of ‘the’ body with 
respect to the wind frame”. 


The matrix eR represents the transformation matrix 





form the Wind Coordinate System to the Inertial Coordinate 


System, where: 


*R=7R?R (10) 


Ww b w 





The matrices ;R and ?R are rotational matrices defined 


by Equations (6) and (7), therefore when both matrices are 





applied to a free vector resolved in the Wind Coordinate 





System {w}, the same vector resolved in the Inertial 





Coordinate System {I} is obtained. 


/RV,, = pR, RV, , = ty (11) 


b,w 


The vector ‘V,, 


stands for “velocity of the body with 


respect to the wind frame solved in the inertial frame”. 











Equation (5) that solves for Wind Estimation can be 


graphically represented by: 








Figure II.15 Wind Estimation Solution 
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IIIT.WIND ESTIMATION MODEL 





Due to the complexity of the model at hand it will be 
presented using smaller modules. 


The general layout of the Wind Estimation Model is 






































regardless the actual rate of incoming heterogenious signals 





shown in Figure ( wk) ¢ 
NPS IMU DATA RECEIVE 
RS-232 | I> C1) 
F | aoa, beta Outt 
Mainboard : R2D 
Setup | 
IMU RS232 input MY Done ie VinGPS 
Calibrating blog 
| IMU Calibration1 | mi 
allbration 
Data PBB data = MMUout | os | beta 
| oe INPUL stioreting block?” T Ye 
Header Header TYPE 9 snout | Out3 
| GPS Calibration1 | par 
DAQ BBI decoder | 2D pat 
| Input stioreting bloce™ | = Wind = 
| 2D Calibration | Vair 
| | Vair 
| | Euler, deg 
arget Scope | | Outs 
Id: 4 | | Yops u 
Scope (xPC) 1 | | VYops 
| | part C6) 
| | GrTr Outé 
| GrTr - — 
| Wind Estimation 
= : : | Vector 
An advantage of Real Time Work Shop / Xpc Target use lies Selections 
in getting output data with the same Output Rate Vairt 
| 
| 
| 


arget Scope 
Id: 6 


Figure III.1 Wind Estimation Model Layout 











Figure ( .1) includes three main sections. The right 








hand side module computes Wind, the central module executes 
necessary calibrations of the incoming data in order to 
obtain physical meaning of it, and the left hand side 


module addresses data capture, i.e., capturing data coming 





from the FROG’s IMU through both Tattletale8 and decoding 
it. 
The above solution was constructed in a SIMULINK 


environment and subsystems/blocks from the xPC Target 


3:1. 


library where included in the capturing/decoding module, so 


a Real-Time Workshop model could be later build. 


A. WIND ESTIMATION SOLUTION MODULE 


The Wind Estimation solution will be based on the 














theory presented on Chapter two (II). Recall Equation (8), 
(9), (6) and (7). 





cos@cos¥ -cos@¢@sin’+singsin@cos¥Y singsin¥Y + cos ¢sin@cosVY 
iv =|cos@sin¥ cosgcos¥+singsin@sin¥ singcos¥ + cosgsin@sin¥Y|>V 


—sing sin ¢ cos 0 cos @ cos @ 


(6) 


cosacos # -cosa@sinf -sina 
V = sin ~ cos B 0 "V (7) 
sina@cos f -sinag@sinf cosa 





From the above set of equations, Wind Estimation will 
be obtained by solving for “*V, (wind velocity in the 


inertial frame). This will be the output of interest for 





the estimation model and the following inputs will be 


needed: 


e V;, (for the model V;,GPS): Obtained from the DGPS 





ground speed. For Wind Estimation purposes only 





components of the x-axis and y-axis are to be 





calculated and considered. In this component 




















calculation, DGPS heading (for the model G,;T,) and 





DGPS ground speed (for the model Vops) are 


required as the inputs. 
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e 
View 


(for the model Vair) ): Obtained from the Air 


Data sensors. Again, for Wind Estimation purposes 








only components of the x-axis and y-axis are to 
be calculated and considered. 


° a and 6 (for the model aoa and beta): Obtained 





from the Air Data sensors. 
° go, 98 and w (for the model phi, theta and psi): 


The Euler Angles are obtained from the angular 





rates p, q and r given by the FROG’s IMU. 


Inertial Velocity 


¥ inertial from DGPS 





Vops 
ms Runway heading 
VinGPS 
Vair bs 
oy =| >a 
: ind 
aoa Selector 
h tai Noise Filter Yair 
Velocity e 
Wind to Body (T) 
Euler, deg 
North/EastDown 
: C5) 
P.4r Noise Filter Angular Rates R201 pq 


Radians to Degrees 


Figure III.2 Wind Estimation Input Visualization and 
General Layout 


Details of the main blocks for the above figure can be 





found in Appendix B. 














In Figure ( -2), the vertical rectangular blocks in 








the center part of the model (green colors) perform the 


mathematics related with j,RV,, = ;R,RV,, and the square 


Ww b,w 
shape block at the top part of the model (magenta color) 
33 


solves for “V7 These two last results are subtracted and 


b,i° 
the Real Wind velocity is obtained. 


The selector on the right hand side of the model 





disregards of the Zz component for the estimated wind, as 
only components of x and y axes are going to be used. 


When solving for the velocity of the platform in the 





inertial frame, the DGPS input for the Ground Track G,T,; 





must consider an initial condition related with the heading 
of the FROG at the take-off position. This is accomplished 
by the subtraction of the constant (293.52627..) that 





corresponds to the orientation of the runway in degrees 


given by the DGPS at the take-off position of the FROG. 





B. DATA RECEPTION MODULE 


The Wind Estimation model uses a RS-232 Mainboard 











block from the xPC Target library of SimuLINK, to setup the 





serial port used for receiving incoming data from the 














Tattletales. As seen on Chapter Two (II.), the arriving 














data will be presented in three different types of sentence 
structures, which can be recognized by its headers. Once 


the data has been received it must be decoded in order to 





obtain the individual input variables that the model will 





handle. 





In the decoding part, first a header must be found in 


the incoming serial data and depending on its 





identification a decoding procedure must be applied to the 
rest of that particular sentence to obtain variables of 


interest. 





To accomplish the header/data identification and the 





later data decoding procedures, software interface drivers 


where written in C Programming and conform to S-function 
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standards [Ref. 5]. Dr. 


this work, 


which is out of the scope of this thesis. 


Vladimir Dobrokhodov (NPS) made 


The, 





codes are included on Appendix B for further reference. 


NPS IMU DATA RECEIVE 





IMU RS232 





arget Scope 
Id: 4 


Scope (xPC)1 


Data 


Figure III.3 















Length 


Constant NPS IMU reciver block 
1 





Enable 


bag Always 
Enable 





NPS IMU Receive 


Figure III.4 


2double1 


IMU RS232 



















Block Parameters: IMU RS1 x 
ts232setup [mask] [link] 


RS-232 
Mainboard 
Setup 








Paametes 
Port: |S ~ | 
Baudrate [3400 ¢@€«0Ci#*~*éi‘((‘(O(N((CCSY 
Number of data bits: jf © §f 
Number of stop bits: 2 | 
| 
Protocot [None titi(‘éOSCSC‘*sS 


Send buffer size: 


fio2a 


Receive buffer size: 


fiozs 


Initialization command structure: 


ee 


Termination command structure: 


_ 
Cancel | Help | Aral | 








Receive Layout and RS-232 Setup 


Block Parameters: NPS IMU Receive xi 





- $-Function 
User-definable block. Blocks may be written in M. C. Fortran or Ada and 
must conform to S-function standards. x.u and flag are automatically 
passed to the S-function by Simulink. "Extra" parameters may be 
specified in the 'S-function parameters’ field. 





y Parameters 





S-function name: 


| teadserial 


S-function parameters: 


[port width,samptime 


Header 











Cancel | Help | Apply | 





Data/Header Block Details 
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Header Type Relational 


Operator 
28 
imudec 


int $-Funetion 








IMU4 


BBI data IMUout 








Relational 
Operator 





Length1 


29 
— | >| oreo | > aD 
IMU2 


GPSout In2 $-Function4 

















BBI decoder 








Relational 
Operator2 






Length2 


16 I 
[] > a2ddec 
S A201 


ind $-Function2 














A2D 


Figure III.5 Data Decoder 


























From Figures ( -4) and ( .5) the written software 














interfaces drivers where “readserial”, which generates the 


output vectors Header and Data; “imudec”, which generates the 





output vector IMUout; “gpsdec”, which generates the output 
vector GPSout, and “a2ddec”, which generates the output 
vector A2Dout (codes for software interfaces drivers are 


included on Appendix B). 


Cc. DATA CALIBRATION MODULE 


The Calibration Module receives three vectors IMUout, 





GPSout and A2Dout. For each vector, every element contains a 
numerical representation of data that has been originally 


measured by a sensor, pre processed by the Tattletales and 





decoded in the Data Reception Module. 

The purpose of the Calibration Module is to perform a 
correlation between those numerical quantities and their 
corresponding value in the MKS Units System, so that every 
measurement performed by a sensor could be used as a 


variable in the Wind Estimation Model. 
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The Wind Estimation Model uses only some elements of 





each vector and they will be explained separately. 


1. The IMUout Vector 


Only five elements of this vector are used as 


variables of the Wind Estimation Model: Angle of Attack 





(aoa), Sideslip Angle (beta) and the three angular rates 





obtained from the IMU’s rate gyros (p, gq and r): 








TE 


1-st smoke 





beta, deg 








r, degis 





p, degis 












2-nd smoke 


IMUout 


Lucy | 


Hx 


























Ax, mis*2 











»| 0.00841 66*(u(1)-2180.58) 
Ay, mis*2 























»{ 0.00868*(u(1)-3068.13)-9.86194 | 


‘ (atone ie tarieseoseendegy 








Figure III.6 Calibration Module IMUout Vector 














For the five variables shown in Figure ( -6) the 








incoming numerical values are converted into Degrees (for 








the angles) and Degrees per Second (for the angular rates). 





Onc these new representations are obtained, Degrees are 





converted to Radians so MATLAB trigonometric functions can be 


later used. 





In order to obtain the mathematical expressions 


contained in the rectangular blocks (blue) of Figure 














( .6), sensor calibration procedures must be carried out. 
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This work was performed in Laboratory under controlled 
environments and consists on obtaining a wide range of 


numerical representations given by the data acquisition 


package of the model (1.e. Tattletale processing and 
decoding procedures) against it corresponding measured 
value. 


The data is then tabulated and the calibration 


equations are obtained via curve fitting tools. 





For Alpha and Beta samples where recorded every 5° over 
a range of + 40° and the following plot of the tabulated 
values was obtained [Ref. 2]: 


Alpha Beta POT Calibration (Done on aircraft) 





@ = = Alpha POT 
@ Beta POT 
— — —Linear (Alpha POT) e 
40 — — —Linear (Beta POT) bE: 


y = 0.0099514x - 129.2 























0 5000 10000 15000 » 20000 25000 





‘eo 
y = -0.0099527x + 170.11 














Voltage [V] 


Figure III.7 Alpha and Beta Sensor Calibration Results 


Comparing the curve fitting equations shown in Figure 




















( .7) with the corresponding blocks of Figure ( ¥O) yp EC 














can be verified that for Beta the equation was applied 
directly. For Alpha, the sign difference was corrected by a 
(-1) multiplication (red triangular block) and a 7.5° 


correction was included because of an angular difference 








between the Alpha vane pod and the longitudinal axis of the 


FROG once the sensor was installed on the wing tip. 
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To obtain angular rate equations (p, gq and r), the 





FROG’s IMU was mounted on a Tilting Rotary Table Model TRT7 





built by, HAAS Automation Inc. and available at the 








Controls Laboratory of the NPS’ Electrical Engineering 





Department. 


An accurate control system provided by the rotary 





table, allowed tilting the IMU at different angular rates 





while numerical values from the rate gyros where obtained 

by the data acquisition package of the model. Again, all 

corresponding data was tabulated and equations where found. 
From the obtained data, constant drift characteristics 


where observed on each gyro and those values where 














corrected as can be seen in Figure ( -6) (green blocks). 








Furthermore, from the sensor calibration procedures it was 








detected that the rate gyros for p and q where oriented in 


the wrong direction. Later this was physically confirmed 





and was corrected by a (-1) multiplication (red triangular 


block). 


2. The GPSout Vector 


Only two elements of this vector are used as variables 





of the Wind Estimation Model: Ground Speed (Vgps) and 
Ground Track (GrTr). 


Both signals are obtained from the DGPS Trimble Ag132 








and do not require any kind of sensor calibration. The 











sentence format shown in Chapter two (II.) is captured and 





decoded by the data acquisition package of the model. 


The only issue that has to be considered at this point 











is that the DGPS velocity given in Knots and the track in 





Degrees. Corrections are made in the red triangular blocks, 





as velocity must be converted to Meters per Second (MKS) 





and Degrees to Radians (MATLAB’S requirement). 
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Long, deg 


Speed knots2m/s 
Track 
oy rac! deg2rad 


Magvar 





Figure III.8 Calibration Module GPSout Vector 


3. The A2Dout Vector 


Only one element of this vector is used as an input 


variable of the Wind Estimation Model: Air Speed (Vair). 





A similar sensor calibration procedure to those used 





for signals in vector IMUout was performed and a quadratic 





equation was implemented in this module. Details of this 


sensor calibration can be found in [Ref. 2]. 


Fen 


u(1}-26463.3)/2.97481 hare ainda 
u(1}*1 
u(1y*1 


RH 






= 











A2Dout 


Figure III.9 Calibration Module A2Dout Vector 
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IV. FLIGHT TEST 


The Wind Estimation Model was constructed in a SIMULINK 





environment using subsystems from the xPC Target library. 


This characteristic of the model allows using MATLAB’s 





Real-Time Workshop to provide a real-tim development 
environment from where Wind Estimation results are 
obtained. 

To accomplish this, FROG is connected with a rapid 


prototyping target computer PC-104 (xPC Target). The target 


computer is linked to the physical sensors and 
microprocessors (Tattletalesg) to carry out data 
acquisition. Real-Time Workshop transforms the Wind 


Estimation Model to C code and creates an executable of the 
model and places it on the target system. 


The model is downloaded from a ground station Host PC 

















via the Data Link assembly described in Chapter Two (II.), 








which also allows the required real-time monitoring of wind 








estimation results. Figure (IV.1) shows the general layout 





of this environment: 


Real-world 





sent/eonteoller: ome ton Vo | A/D, D/A, DIO, counters 
Hard er CAN, RS232, GPIB 


t 4 


















































Host PC Target PC 
PC Hardware: desktop/PC104/ 
Compact PCI, SBC, etc. 
MATLAB PCIISA Bus; more than fifty 
Simulink I/O devices supported 
RTW Real-Time Kernel 
xPC Target (32 hit protected mode) 
RIW- generated application ——-» 
Host-Target 





Communication 
<#—- Parameter tuning, monitoring, etc. ——® 


Figure IV.1 xPC Target Environment [From Ref. 6] 
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A. FLIGHT TEST PROFILE AND GENERAL PROCEDURES 


The FROG was flown at the McMillan Airfield at Camp 
Roberts, California on 9 October 2002. The main objective 


of the test was to verify the Wind Estimation Model by 





comparing its wind estimation results against real wind 
measurements performed by the NPS Meteorology Department. 
The flight profile for the UAV was straight and level 


passes on the runway heading with a turn at each end at an 





approximate flight level of 50 feet AGL. Figure (IV.1) 
shows the flight profile of the test flight obtained with 
the GPS unit onboard the FROG and an aerial photo of the 


airfield. The flight profile is in GPS coordinates 








(Longitudinal Minutes versus Lateral Minutes). 





























42.9 42.95 43 43.05 43.1 43.15 43.2 43.25 43.3 


GPS Lat Min 





Figure IV.2 Flight profile of FROG during test flight 
(left) and McMillan Airfield (right) 


NPS Meteorology Department performed data collection 
at the demonstration site. The collection was done with 
three ground-stations and one Rawinsonde system (balloon), 
which allowed a 3-D description of the tested air volume. 

The ground station systems operated continuously 


during the entire time collection period. The Rawinsonde 
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system was used at scheduled times to collect profiles of 


vector winds, temperature, and humidity. 





For the continuous ground-based measurements, portable 
instrumented meteorological towers were installed on 
October 2, 2002 in continuous operation mode until removed 


October 10, 2002. The tower designation and location were: 


West Tower: 50 ft South of the NW end of the runway. 
East Tower: on a hill several hundred ft North of the 
midpoint of the runway. 


North Tower: 50 ft north of the SE end of the runway. 





Figure IV.3 Instrumented Portable Meteorological Tower 


The towers were instrumented for true vector wind 
(speed and direction reference to true North), air 


pressure, air temperature and humidity. The sensors were 





sampled at 1 Hz and the output averaged over a two-minute 


interval. 
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B. TEST FLIGHT RESULTS 


Validation of the Wind Estimation Model was based ona 





nine-minute flight at 50 ft high over McMillan Airfield, 
following the flight profile showed on Figure (IV.). The 





data collected during the flight was used to estimate wind 
and compare it to measured true wind by the meteorological 


equipment. 


Validation legs were referred to the runway 





orientation of 290° so data of interest was collected during 





general DGPS headings of 300° and 120°. The average speed 





for the FROG for the valid paths was 66 knots. 


Next figure presents the results of wind direction and 





velocity (left side) as well as the data collected by the 
meteorological towers (right side). This data corresponds 


to a general heading of the FROG of 280°. 
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Figure IV.4 Wind Estimation Results Straight Path 
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Summary of the comparison of the averaged results is 


presented in a table below. 
































Wind Magnitude Wind Direction 
Real-Time Model ae 
Results pre nrS ae 
Met logical 
ae 4.9 m/s 214° 
Measurements 
Error l= 3 m/s =o" 
Table IV.1 Wind Results Comparison 


From the above table we have: 


a 
North 









Wind 
Estimation 
model 


Meteorological 
data 


Figure IV.5 Wind Direction Results 


Clearly, the wind velocity and direction results match 
those obtained by the meteorological towers fairly well. 


This comparison indicates that Wind Estimation based on the 





UAV sensors was successful. 
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Cc. REAL-TIME PRESENTATION FOR WIND ESTIMATION 





Th real-time presentation of the results was done 
using SimuLInK/Real-Time Workshop available features. 


A simple SIMULINK model as the one shown in Figure 





(IV.6) can be run on the Host PC. The “From xPC Target” 








blocks available in the xPC Library capture real-time 


output variables from the Wind Estimation Model. This is 








possible since both computers are connected via the Data 
Link assembly. 
Once these variables are available in the SIMULINK 


model, they can be mathematically related and results can 





be displayed using blocks from the Dials and Gages Library. 





This can be seen in Figure (IV.6): 


From xPC Target 


Generic Numeric LED 


From xPC Target 1 


Generic Numeric LED1 









Trigonometric 
Function 








Compass 







From xPC Target 2 







Generic Numeric LED2 





Math 
Function 








From xPC Target3 






Math 
Function2 






Generic Numeric LEDS 








Generic Numeric LED4 


Math 
Function 


Figure IV.6 Real-Time Presentation Example 
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Vv. CONCLUSIONS AND RECOMENDATIONS 


A. CONCLUSIONS 


The primary goal of this thesis was to obtain real- 


time Wind Estimation based on data collected by embedded 





sensors of a UAV platform and to validate those results by 
a comparison to wind measurements obtained by calibrated 


meteorological equipment. 





Highly accurate meteorological and navigation 








information has been obtained during the flight tests that 








prove the efficiency of the UAV employment. Developed 


hardware architecture has confirmed the idea of a real-time 





data acquisition airborne unit for the task of 





meteorological prediction. 





Currently employed hardware components provide a state 


of the art in portability of UAV system deployment. Created 








real time software has shown its compatibility with real- 
time processing requirements, adequate accuracy and 
robustness. 

Analyzed results have revealed a significant potential 


and promising direction in UAV based system that should be 





further addressed. 


B. RECOMMENDATIONS 


Future work would include an improvement of hardware 














design that allows more flexibility in hardware rigging. It 
should support an exchangeable utilization of more precise 
and numerous heterogeneous sensors including a “full” 





variety of possible chemical/biological agents detectors. 





Software enhancement should address two principal 


issues that allow moving the project onto direction of 
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increased autonomy. The EUS topic includes an 
implementation of complimentary filtering technique to 
provide better resolution of the heterogeneous information 








from variety of possible sensors. The other issue should 








address the development and implementation of pilot support 


tools to extend the operational area and simplify 











navigation task. It can be achieved by the development 
implementation of such trajectory pattern (grid) where 


is autonomously guided and also by employing a modern 





based technigue through th real-tim visualization 


navigational data. 
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the 
and 
UAV 
GPS 

of 


196 UAVs: USA 
BAI TERN 
Type 


Multipurpose, semi-expendable UAV. 


Development 

The TERN (Tactical Expendable Remote 
Navigator} was originally designed and 
developed by H-Cubed Corporation of 
Columbia, Maryland. The programme was 
acquired by BAI Aerosystems in 1993. 
Capable of a variety of applications, it is 
recoverable in peacetime training missions 
but of sufficiently low cost that it could be 
discarded after a battlefield mission if 
necessary. On 1 October 1992, a TERN set 
up an endurance record in FAI Class F3a 
for unmanned aircraft of 33 hours 39 
minutes 15 seconds. A_ straightline 
distance record in the same class was set 
on 28 September 1993 with a flight of 
245.80 n miles (455.23km; 282.87 
miles). 


Airframe 

Pod-and-boom fuselage = with —_high- 
mounted wing, sweptback fin and rudder, 
and low-set tailplane: wing fitted with flaps; 
GFRP/epoxy construction. Engine 
mounted above wing centre-section; fixed 
tricycle landing gear. 


Mission payloads 

Can include colour TV camera, thermal 
imager or hazardous agent sensors. One 
variant (TERN-C) has carried a remote IR 
sensor for aerial detection of chemical 
warfare agents. Another (FOG-R) has been 
fitted with an Optelecom Fibre Optic 
DataLink (FODL) and flown non-line of 
sight ‘over and below the hill’ for uplink 
command of the UAV and downlink video 
imagery. The latter version is stated to be 
proof against jamming. 


Guidance and control 

UHF (400 MHz) radio command uplink for 
remote control; D-band (1.8 GHz) video 
downlink with data sideband. Options 
include programmable autopilot, GPS 
navigation and fibre optic datalink. Wing 
flaps can be trimmed to enable slow flight 
speeds for surveillance, or fully extended to 
assist landing in restricted spaces. 


Transportation 
Wings detach for containerised storage 
and transportation. 


Launch 
Conventional wheeled take-off. 


Recovery 
Conventional wheeled landing. 


Operational status 
In production. 


Customers 

Has been used by US Army as surrogate 
fibre optic guided missile (FOG-M) and as 
an NBC sensor vehicle. Also used by Naval 
Weapons Center and ARDEC. 


Prime contractor 
BAI Aerosystems Inc, Easton, Maryland. 


April 1999 


Figure A. 1 


APPENDIX A. DESCRIPTION OF THE FOG-R 


BAI TERN semi-expendable multirole UAV 








TERN air vehicle three-view (Jane’s/John W Wood) 


Power plant 
blade fixed-pitch wooden propeller. 


Dimensions 
Wing span 
Wing area 
Length overall 
Height overall 
Wheel track 


Weights 
Weight empty 
Max payload 
Max T-O weight 


Performance 

Max level speed 

Normal cruising speed 

Loiter speed 

Stalling speed 

* Range 

Typical endurance at above cruising 
speed 

* Extendable in autonomous flight mode 





One 7.5 kW (10 hp) 150 cc two-cylinder two-stroke engine (type not known); two- 





1998 


3.10 m (10 ft 2.0 in) 
1.57 m? (16.94 sq ft) 
2.48 m (8 ft 1.5 in) 
0.86 m (2 ft 10.0 in) 
0.74 m (2 ft 5.0 in) 


17.7 kg (39.0 Ib) 
13.6 kg (30.0 Ib) 
34.0 kg (75.0 th) 


70 kt (129 km/h; 80 mph} 

48-52 kt (88-96 km/h; 55-60 mph) 
35-43 kt (64-80 km/h; 40-50 mph) 
31kt(57 km/h; 35 mph) 

8.6 n miles (16 km; 10 miles) 


3h 








JUAVT-ISSUE 11 


FROG Main Characteristics 
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UAV (NPS FROG) 
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APPENDIX B. WIND ESTIMATION MODULE DESCRIPTION 


The objective of this appendix is to provide a 


detailed description of the Wind Estimation Module used in 





the Wind Estimation Model. Mathematics in this appendix 














refer to Chapter Two (I1I.) 





On Figure (B.1), the blue blocks correspond to SIMULINK 





library Variable Selectors that provide the necessary 


inputs to the module: 







NPS IMU_DATA RECEIVE After the calibration blocks 


all values refer to 
International Units (kg, m, s) 


RS-232 





























Mainboard aoa, beta 
IMU RS232 IMU a08 
INU, trating bloden® VinGPS 
u 
IMU Calibration1 cai 
GPS 
INPUL, sjiorating blog” ve 
GPS Calibration1 par 
A2D 
INPUL, sibrating bode wind = 
A2D Calibration1 Vair 
arget Scope Euler, deg 
Id: 4 Vops Outs 
Scope (xPC) 1 
part eC 6) 
GrTr outé 












GrTr 





Wind Estimation 





An advantage of Real Time Work Shop / Xpc Target use lies S bral s 
in getting output data with the same Output Rate 
regardless the actual rate of incoming heterogenious signals 
Id: 6 
Figure B.1 Wind Estimation Module General Layout 


SL 





The Wind Estimation Block (white on Figure B.1) mainly 


contains: 





Inertial Velocity Block (magenta). 





Velocity Wind to Body Block (light green). 


North/East Down Block (dark green). 














Recall Figure ( oa) 2 





Inertial Velocity 










¥ inertial from DGPS 












Vaps 
eet Runway heading 
VinGPS 
Vair —. 
©) tr 
aoa Selector 
b ta Noise Filter Vair 
Velocity e 
Wind to Body (4) 
Euler, deg 
Norh/EastDown 
PT Noise Filter Angular Rates R201 part 
Radians to Degrees 
Figure B. 2 From Chapter Three Figure (III.2) 





For the Inertial Velocity block we have: 





uGPS 





Figure B.3 Inertial Velocity Block. 


Note that the w component of the DGPS velocity is 
cancelled. 


BZ 


For the Velocity Wind to Body Transformation block we 


have: 







soasbets Wind to Body 


Matrix 


wind frame Multiply 





Velocity 
Wind to Body 


cogu[1]¥ coxu[2]) 
m -coxu[1]¥sin(u[2]) m 
-sin(u[1]) 


aoa/beta sin(u[2]) 


ec ‘ 
| 2 s*”T me 
Reshape 
| 8 
sin(u[1]f coxtu[2]) 


-sin(u[1]¥sinfu[2]) ” 
costu[1]} 


Row to Column 
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Wind to Body Rotation Matrix 


Figure B.4 Wind to Body Transformation 


For the Wind Frame input only the x component is 


considered. This represents the impact wind over the pitot 





tube of the UAV (longitudinal axis). 


53 


For the North/East/Down block we 


have: 











DCM Reshape 
from Euler Angles 9x1-> 3x3 


Discrete-Time 
Integrator 











W2=0 Ve 
Product 






phi, theta, psi Vio 


North/EastDown 


3} cos(u[3})*cos(u[2]}) 
on (eee eee a 


sin{u[3]})*cos(u[2]) 


es es 


-sin(u[2)) 


- cos(u[3})*sin(u[2}*sin(ult})-sin(u[3}*cos(ult]) -_ 


sin(u[3)})*sin(u[2})*sin(u[1}j+cos(u[3})*cos(ul[t}) 


7 cos(u[2})*sin¢(u[1]) _ | 


cos(u[3))*sin(ul2)*cos(ut )+sin(ufsy*sin(ultp 


™ sin(u[3)*sin(u[2})*cos(ult))-costu[3})*sin(u[1)) a 
cos(u[2})*cos(u[t)) 
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DCM 


DCM from Euler Angles 


Figure B.5 Body to Inertial Transformation 


And for the “phidot thetadot psidot” block we have: 






u[1]tu[2]}*sin(u[4]ftan(u[S)}} u[3]* costu [4] Ftan(u[s]) 


u[2}*costu[4)}-u[S}*sintu[4y) 






thetadot phidot 
thetadot 
ul2Fsin(u[4]¥costu[5] + u[3 coxu[4]¥costu[5]) psi 


psidot 


Figure B. 6 Phidot Thetadot Ppsidot Block 
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APPENDIX C. SOFTWARE DRIVERS 


This appendix contains the C Programming source code 


written to receive and decode the data streams from the 











FROG’s IMU. Dr. Vladimir Dobrokhodov wrote these drivers. 


All the C-codes had to be packaged into MATLAB’s S-Function 





Level 2 structure which adopts a specific sequence to 
initialize a simulation block, update its states, control 
sampling rates, output data and terminate the function. 
Fach set of code has to be “MEX” by a compatible C-compiler 
in MATLAB and ‘build’ into executable code by xPC’s Real- 


Time Workshop before it can be called from within a SIMULINK 





block as a S-Function. Details of how this is done are 


discussed in [Refs. 5 and 6]. 


1. SERIAL DATA RECEIVE DRIVER 
readserial.c 


/* $Revision: 1.1 $ $Date: 2001/07/20 22:11:41 $ */ 

/* rs232rec.c — xPC Target, non-inlined S-function driver for RS-232 */ 
/* receive (asynchronous) */ 

/* Copyright 1996-2001 The MathWorks, Inc. */ 








#define S_FUNCTION_LEVEL 2 
undef S_FUNCTION_NAM 
#define S_FUNCTION_NAM 











|e i | 


readserial 


#include <stddef.h> 
include <stdlib.h> 





#include "tmwtypes.h" 
#include "simstruc.h" 





ifdef MATLAB MEX FILE 
include "mex.h" 











lude <windows.h> 

lude <string.h> 

include "rs232_xpcimport.h" 
1 
£ 








lude "time_xpcimport.h" 
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/* Input Arguments */ 






































#define NUMBER_OF_ARGS (3) 

#define PORT_ARG ssGetSFcnParam(S, 0) 
#define WIDTH_ARG ssGetSFcnParam(S,1) 
#define SAMP_TIME ARG ssGetSFcnParam(S, 2) 
#define NO_I_ WORKS (3) 

#define NO_R_WORKS (0) 

#define NO_P_WORKS (0) 

#define NO_D_ WORKS (1) 

#define HEADER (36) 

static char_T msg[256]; 

extern int rs232ports[]; 





/*Number of parameters in 
a block parameters 
dialog */ 

/*Number of Serial Port*/ 

/*Maximum width of 
INCOMING sentence per 
packet*/ 

/*Sample time*/ 


/*Current pos pointer in 
buf, rec length, 
bufCount*/ 


/*for buf array*/ 


PrS= Signy 


unsigned char remains; /*global array to save remains after 
subtracting procedure*/ 


static void mdlInitializeSizes(SimStruct *S) 





{ 
#ifndef MATLAB MEX_FILE 
#include "rs232_xpcimport.c" 
#include "time_xpcimport.c" 
#endif 

















ssSetNumSFcnParams (S, NUMBER_OF_ARGS) ; 


if (ssGetNumSFcnParams(S) != ssGetSFcnParamsCount(S)) { 
sprintf (msg,"Wrong number of input arguments passed.\n" 
"Sd arguments are expected\n",NUMBER_OF_ARGS) ; 





ssSetErrorStatus (S,msq) ; 
return, 


} 
/* Set-up size information */ 


ssSetNumContStates( S, 0 
ssSetNumDiscStates( S, 0 
ssSetNumOutputPorts(S, 3 
ssSetNumInputPorts( S, 2 





7 /*func-call,data, header index*/ 
: /*rec length, enable*/ 


ssSetOutputPortWidth(S, 0, 1); /*Function-call*/ 


ssSetOutputPortWidth(S, 1, (int)mxGetPr(WIDTH_ARG) [0]); /*Data*/ 


ssSetOutputPortDataType(S, 1, SS_UINT8); 


ssSetOutputPortWidth(S, 2, 1); 
ssSetOutputPortDataType(S, 2, SS_UINT8); 








ssSetInputPortDirectFeedThrough(S, 0, 1); 
ssSetInputPortDirectFeedThrough(S, 1, 1); 
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/*Header index*/ 


ssSetInputPortWidth (Ss, 
ssSetInputPortWidth (Ss, 


ssSetInputPortRequiredContiguous(S, 0, 1); 
ssSetInputPortRequiredContiguous(S, 1, 1); 


ssSetNumSampleTimes(S,1); 


ssSetNumIWork(S, 
ssSetNumRWork (S 
ssSetNumPWork(S, NO_P_WORKS 
ssSetNumDWork (S 


ssSetDWorkDataType(S, 
ssSetDWorkWidth(Ss, 
ssSetDWorkWidth(Ss, 


ssSetNumModes(S, 





0, 
0, 


0); 


ssSetNumNonsampledZCs ( 


NO_I_WORKS) 

, NO_R_WORKS); 
) 

) 


, NO_D_WORKS 


0, 


, 


, 


i 


SS_UINT8); 


(int)mxGetPr (WIDTH_ARG) [0]); 


204 


Ss, 


8); 


0); 


/* This S-function’s parameters cannot be changed in the middle of */ 
hence set them to be non-tunable. */ 


/* a simulation, 


{ 


int_T ntune; 


for (ntune=0; 


} 
ssSetOptions 


} 


/* Function to iniietal 


static void mdliInitial 





ntune < NUMBER_OF_ARGS; ntunett+) { 
ssSetSFcnParamNotTunable(S, ntune); 


(S, SS_OPTION_EXCEPTION_FREE_CODE | 
SS_OPTION_PLACE_ASAP) ; 





{ 


ssSetSampleTime(S, 
if (mxGetN ((SAMP_T 
ssSetOffset! 


} else { 


ssSetOffset! 


} 


0, 











Time (S, 


IM 





Time (S, 





lize sample times */ 


izeSampleTimes (SimStruct *S) 


mxGetPr (SAMP_TIME_ARG) [0]); 


0, 


0, 


ssSetCallSystemOutput (S, 


} 


/* Punction?e mdlstart 


_ARG))==1) { 


O:2 O)s9 
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mxGetPr (SAMP_TIME_ARG) [1]); 


0); 





/* 





/* Abstract: 


/* At the start of simulation in RTW, print a message to the MATLAB 


/* command window indicating that something is going on. 


#define MDL_START 


#if defined (MDL START) 
static void mdlStart (SimStruct *S) 


{ 





#ifndef MATLAB M 





EX FILE 








ssGetIWork(S) [0] = 


0; 


/*Change to #undef to remove function*/ 


/* set current buf pointer = 0 */ 


Sf 


ys 
ws 
ed 
ef 
ad 


ssGetIWork(S) [2] = 0; /* set. butCount = 0 */ 


printf("\n readserial.c: This is a beginning of data logging 
procedure"); 


#endif 


} 
#endif 


/* Function to compute outputs */ 
static void mdlOutputs(SimStruct *S, int_T tid) 


{ 
#ifndef MATLAB MEX FILE 














int width = (int)mxGetPr(WIDTH_ARG) [0]; /*specify output port width 
=WIDTH_ARG that is the max 
length of GPS sentence*/ 


int port = (int)mxGetPr(PORT_ARG )[0] - 1; /*specify COM#*/ 
unsigned char tmp; /*temp char holder*/ 
unsigned char *buf = (unsigned char *)ssGetDWork(S, 0);/*uchar buffer 


to contain bytes 

from serial port*/ 
int *current = ssGetIWork(S); /*current = addr of current position 

pointer in buffer*/ 
int *recLength = ssGetIWork(S) + 1; /*recLength = addr of received 
data length*/ 
int *bufCount = ssGetIWork(S)+ 2; /*count number of useful bytes in 
buffer*/ 





int serbufCount; /*count number of useful bytes collected in Serial 
buffer*/ 
int i, j,checksum; 
int *bl_header; /*boolean values for IMU=1, GPS=2 and A2D=3 
sentences, O=nothing found*/ 
int headwidth=2; /*length of header except*/ 
int imulng=28,gpslng=31,a2dlng=18; /*initialize length of 
IMU (28) ,GPS(29+2{CR,LF}) and 
A2D (16+2{CR,LF}) sentences without 
header* / 


if (ssGetInputPortRealSignal(S, 1)[0] == 0) /*If there is no bytes 
available so function is disabled. Stop 
processing and get out */ 
FSeturn; 


serbufCount = rl32eReceiveBufferCount (port); /*Check number of 
bytes available*/ 


while (serbufCount) { /*transfer everything from serial buffer to 
buffer*/ 
tmp = rl32eReceiveChar (port) ; 
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if ((tmp & Oxff00) != 0) { /*only last 8 bits can be 
non-zero*/ 





printf ("RS232Receive Error: char & Oxff00 != 0 \n"); 
return; 

} 

buf[(*current)++] = tmp & Oxff; /*put valid char into buffer 


& means if both operand equal 
to 1 the output assigns to 1*/ 
serbufCount--; /*reduce serbufCount*/ 
(*bufCount) ++; /*increase bufCount correspondingly*/ 


if (*bufCount < width) return; /*Not enough bytes to decode, 
output old value*/ 


/* Initialize logical flags* / 





i= 0; 


while (((buf[i]==221 && buf[itl]==221) || 
(buf [i]==238 && buf[it+1]==238) || 





(buf [i]==255 && buf [itl]==255)) == 0 && I < (*bufCount-1)) 
{ i=it+l; } /*end of while. Just looking for any first 
header*/ 


/* Begin to substruct corresponding arrays if we have enough bytes */ 
while (itmax(max(imulng,gpsing), a2dlng) <= (*bufCount) ) { 


checksum = buf[i]*256 + buf[it+l]; 
i=i+ 2; 


if (checksum==65535 & it+timulng <= (*bufCount) ) { 
/*IMU Header FF FF -255 255 take imulng bytes and 
send it out*/ 
*bl_ header=1; /*IMU found*/ 
memcpy (ssGetOutputPortSignal (S,1),buf+i,imulng) ; 


i =i + imulng; /*next byte to process*/ 
} /*if checksum matches*/ 
if (checksum == 61166 & itgpslng <= (*bufCount) ) { 


/*GPS Header EE EE -—238 238 take imulng bytes and 
send it out*/ 
*bl_ header=2; /*GPS found*/ 
memcpy (ssGetOutputPortSignal (S,1),buf+i,gpsing) ; 
i= i+ gpsling; /*next byte to process*/ 
} /*if checksum matches*/ 


if (checksum == 56797 & ita2dlng <= (*bufCount) ) { 
/*A2D Header DD DD -221 221 take imulng bytes and 
send it out*/ 
*bl_header=3; /*A2D found*/ 
memcpy (ssGetOutputPortSignal (S,1),buf+i,a2dlng) ; 
i =i + a2dlng; /*next byte to process*/ 


Do 


} /*if checksum matches*/ 
/*end of subtracting while*/ 


/* Send Header index to know how much bytes has to be decoded in each 
message */ 


memcpy (ssGetOutputPortSignal(S,2),bl_header,1); 
} /*end of while*/ 


/* Substitute remain bytes from this step at the beginning of "buf" 
save remain bytes into the "buf" and shift current to the end of 
a new buffer */ 
if (i<(*bufCount) ) { 
*bufCount=*bufCount-i; //number of remain bytes 


for (j=0; 3<*bufCount; j++) {buf[j]=buf[i];it+;} /*end of for*/ 


*current=*bufCount; 


} 
ssCallSystemWithTid(S, 0, 0); /*issue done pulse to outport 0*/ 
return; 


#endif 
} 


/* Function to perform housekeeping at execution termination */ 





static void mdlTerminate(SimStruct *S) 




















#ifdef MATLAB MEX _ FILE /*Is this file being compiled as a MEX-file?*/ 
#finclude "simulink.c" /*MEX-file interface mechanism*/ 

else 

#include "cg_sfun.h" /*Code generation registration function*/ 
#endif 


2. ANALOG TO DIGITAL DATA RECEIVE DRIVER 


a2ddec.c 
/* File : a2ddec.c 
SRevision: 1.00 $V.Dobrokhodov */ 


#include <stdlib.h> 
Hinclude <math.h> 
#Hinclude <stdio.h> 
#include <iostream.h> 
Hinclude <string.h> 








#define S_FUNCTION_NAME a2ddec 
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#define S_FUNCTION_LEVEL 2 
#include "simstruc.h" 











/* Input Arguments */ 


#define NUMBER_OF_ARGS (1) 
#define WIDTH ssGetSFcnParam(S,0) /*WIDTH is the max. length of 
incoming IMU sentence*/ 








/* Build checking */ 

static char_T msg[256]; 

/* Function: mdlinitializeSizes 
Abstract: 


Setup sizes of the various vectors. */ 


static void mdlInitializeSizes(SimStruct *S) 


{ 





ssSetNumSFcnParams (S, NUMBER_OF_ARGS) ; 


if (ssGetNumSFcnParams(S) != ssGetSFcnParamsCount(S)) { 
sprintf (msg,"Wrong number of input arguments passed.\n" 
"Sd arguments are expected\n",NUMBER_OF_ARGS) ; 
ssSetErrorStatus (S,msq) ; 
return; /*Parameter mismatch will be reported by Simulink*/ 








if (!ssSetNumInputPorts(S, 1)) return; 


ssSetInputPortWidth(S, 0, int)mxGetPr (WIDTH) [0]) ;/*DYNAMICALLY_SIZED 


ssSetInputPortDirectFeedThrough(S, 0, 1); 
if (!ssSetNumOutputPorts(S,1)) return; 


ssSetOutputPortWidth(S, 0, 8); /*A2D length=8 DYNAMICALLY_SIZED*/ 
ssSetNumSampleTimes(S, 1); 


/* Take care when specifying exception free code. See sfuntmpl_doc.c */ 


ssSetOptions(S, SS_OPTION_EXCEPTION_FREE_CODE | 
SS_OPTION_USE_TLC_WITH_ACCELERATOR) ; 























/* Function: mdlInitializeSampleTimes 
Abstract: 
Specifiy that we inherit our sample time from the driving block */ 


static void mdlInitializeSampleTimes (SimStruct *S) 


{ 





ssSetSampleTime(S, 0, INHERITED_SAMPLE_TIME) ; 
ssSetOffsetTime(S, 0, 0.0); 
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/* Function: mdlOutputs */ 


static void mdlOutputs(SimStruct *S, int_T tid) 


{ 


int_T 1i=0,  j3=0; 

InputRealPtrsType uPtrs = ssGetInputPortRealSignalPtrs(S,0); 
/*Incoming data stream*/ 

real_T *y = ssGetOutputPortRealSignal(S,0); 

int_T temp[100]; /*make an aliase for the uPtrs*/ 

char ext[]="\0"; 

int count=0, len_in; 


for 


for 


} 


(1=0; i<(*uPtrs[0]); itt) {temp[i] = ( int_T) (*uPtrs[i+1]);} 
(i1=0; i<(*uPtrs[0])) { 

*y++=(real_T) (temp[it+0]*256 + temp[it1]); 

i=i+2; 





/*from GPSAtoDO to GPSAtoD7*/ 


/* Function: mdlTerminate 
Abstract: 
No termination needed, but we are required to have this routine. */ 


static void mdlTerminate(SimStruct *S) 





{ 
} 





#ifdef MATLAB _MEX_FILE /*Is this file being compiled as a MEX-file?*/ 














#include "simulink.c" /*MEX-file interface mechanism*/ 

#else 

#include "cg_sfun.h" /*Code generation registration function*/ 
#fendif 

3. GPS DATA RECIEVER DRIVER 

gpsdec.c 

/* File gpsdec.c 


SRevision: 1.00 $V.Dobrokhodov */ 


#incl 
#incl 
Fincl 
#incl 
Hincl 





lude 
lude 
lude 
lude 
lude 





#define S_FUNCTION_NAME 
#define S_FUNCTION_LEVE 


tinclude 


<stdlib.h> 
<math.h> 
<stdio.h> 
<iostream.h> 
<string.h> 

















"simstruc.h" 


/* Input Arguments */ 
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#define NUMBER_OF_ARGS (1) 
#define WIDTH ssGetSFcnParam(S,0) /*WIDTH is the max length of incoming 





IMU sentence */ 


/* Build checking */ 


static char_T msg[256]; 


/* Function: mdlinitializeSizes 


Abstract: 
Setup sizes of the various vectors. */ 


static void mdlInitializeSizes(SimStruct *S) 


{ 





ssSetNumSFcnParams (S, NUMBER_OF_ARGS) ; 
if (ssGetNumSFcnParams(S) != ssGetSFcnParamsCount (S) ) { 
sprintf (msg,"Wrong number of input arguments passed.\n" 
"Sd arguments are expected\n",NUMBER_OF_ARGS) ; 
ssSetErrorStatus (S,msqg) ; 
return; /*Parameter mismatch will be reported by Simulink*/ 








if (!ssSetNumInputPorts(S, 1)) return; 

ssSetInputPortWidth(S, 0, (int)mxGetPr(WIDTH) [0]); 
/*DYNAMICALLY_SIZED*/ 

ssSetInputPortDirectFeedThrough(S, 0, 1); 

if (!ssSetNumOutputPorts(S,1)) return; 


ssSetOutputPortWidth(S, 0, 12); /*GPS length=12 DYNAMICALLY_SIZED*/ 
ssSetNumSampleTimes(S, 1); /*Take care when specifying exception 





free code - see sfuntmpl_doc.c */ 
ssSetOptions(S, SS_OPTION_EXCEPTION_FREE_CODE | 


SS_OPTION_USE_TLC_WITH_ACCELERATOR) ; 









































} 





/* Function: mdlInitializeSampleTimes 
Abstract: 
Specifies that we inherit our sample time from the driving block. 


static void mdlInitializeSampleTimes (SimStruct *S) 


{ 





ssSetSampleTime(S, 0, INHERITED_SAMPLE_ TIME) ; 
ssSetOffsetTime(S, 0, 0.0); 





} 
/* Function: mdlOutputs */ 


static void mdlOutputs(SimStruct *S, int_T tid) 

{ 
int_T i=0, j=0; 
InputRealPtrsType uPtrs = ssGetInputPortRealSignalPtrs(S,0); 

/*Incoming data stream*/ 

real_T *y = ssGetOutputPortRealSignal(S,0); 
int_T temp[100]; /*make an aliase for the uPtrs*/ 
char ext[]="\0"; 
int count=0, len_in; 
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for (i=0; i<(*uPtrs[0]); i++) {temp[i] = ( int_T) (*uPtrs[itl]);} 

















































































































xy (real_T) (temp[0]); 

ay) (real_T) (temp[1]); 

ky (real_T) (temp[2] + temp[3]/10); 

*Vy (real_T) (temp[4]); 

*Vy (real_T) (temp[5] + (temp[6]*2%24 + temp[7]*2%16 + 
temp [8]*2*°8+ temp[9])/1000000) ; 

xy (real_T) (temp[10]); 

*y (real_T) (temp[11] + (temp[12]*2*24 + temp[13]*2*16 + 
temp [14]*2*°8 + temp[15])/1000000) ; 

ou (real_T) (temp[16]); 

ky (real_T) (temp[17]*256 + temp[18] + temp[19]/100); 

*y (real_T) (temp[20]*256 + temp[21] + temp[22]/100); 

*y (real_T) (temp[23]*256 + temp[24] + temp[25]/100); 

ky (real_T) (temp[26]*256 + temp[27] + temp[28]/10); 











} 





/* Function: mdlTerminate 
Abstract: 
No termination needed, but we are required to have this routine. */ 





static void mdlTerminate(SimStruct *S) 
{ 
} 





#ifdef MATLAB _MEX_FILE /*Is this file being compiled as a MEX-file?*/ 














#include "simulink.c" /* MEX-file interface mechanism*/ 

#else 

#include "cg_sfun.h" /*Code generation registration function*/ 
#fendif 


4. IMU DATA RECEIVE DRIVER 


imudec.c 
/* File : imudec.c 
SRevision: 1.00 $V.Dobrokhodov */ 


#include <stdlib.h> 
Hinclude <math.h> 
Hinclude <stdio.h> 
#include <iostream.h> 
Hinclude <string.h> 





#define S_FUNCTION_NAME imudec 
#define S_FUNCTION_LEVE 




















#include "simstruc.h" 
/* Input Arguments */ 


#define NUMBER_OF_ARGS (1) 
#define WIDTH ssGetSFcnParam(S,0) /*WIDTH is the max length of incoming 
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IMU sentence*/ 
/* Build checking */ 


static char_T msg[256]; 
/* Function: mdlInitializeSizes 


Abstract: 
Setup sizes of the various vectors. */ 








static void mdlInitializeSizes(SimStruct *S) 


{ 
ssSetNumSFcnParams (S, NUMBER_OF_ARGS) ; 


if (ssGetNumSFcnParams(S) != ssGetSFcnParamsCount (S) ) { 
sprintf(msg,"Wrong number of input arguments passed.\n" 

"Sd arguments are expected\n",NUMBER_OF_ARGS) ; 

ssSetErrorStatus (S,msq) ; 

PrScurn; /*Parameter mismatch will be reported by Simulink*/ 








if (!ssSetNumInputPorts(S, 1)) return; 


ssSetInputPortWidth(S, 0, int)mxGetPr(WIDTH) [0]); 
/* DYNAMICALLY _SIZED* / 


ssSetInputPortDirectFeedThrough(S, 0, 1); 


if (!ssSetNumOutputPorts(S,1)) return; 

ssSetOutputPortWidth(S, 0, 14); /*IMU length=14 DYNAMICALLY_SIZED*/ 

ssSetNumSampleTimes(S, 1); /*Take care when specifying exception 
free code - see sfuntmpl_doc.c */ 


ssSetOptions(S, SS_OPTION 
SS_OPTION_US 


EXCEPTION_FREE_CODE | 
TLC_WITH_ACCELERATOR) ; 














1 








} 





/* Function: mdlInitializeSampleTimes 
Abstract: 
Specifies that we inherit our sample time from the driving block. */ 


static void mdlInitializeSampleTimes(SimStruct *S) 


{ 





ssSetSampleTime(S, 0, INHERITED_SAMPLE_ TIME) ; 
ssSetOffsetTime(S, 0, 0.0); 





} 
/* Function: mdlOutputs */ 


static void mdlOutputs (SimStruct *S, int_T tid) 
{ 
int_T 1i=0,j=0; /*Incoming data stream, *uPtrs[0]- determine the 
length of useful bytes{28 for the IMU}*/ 
InputRealPtrsType uPtrs = ssGetInputPortRealSignalPtrs(S,0); 
real_T *y = ssGetOutputPortRealSignal(S,0); 
/*int_T width = ssGetOutputPortWidth (S,0);*/ 


int_T temp[100]; /*make an aliase for the uPtrs*/ 
char ext[]="\0"; 
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int count=0,len_in; 





for (i=0; i<(*uPtrs[0]); i++) {temp[i] = ( int_T) (*uPtrs[i+1]);} 
for (i=0; i<(*uPtrs[0])) { 

*y++=(real_T) (temp[it+0]*256 + temp[itl]); 

4=it2; 


/*notused(j,1), airtemp, airspeed,q, r, p, phi ,tetta, Hx, Hy, 
Hz, Ax, Ay, Az*/ 
} 
/* Function: mdlTerminate 
Abstract: 
No termination needed, but we are required to have this routine. */ 


static void mdlTerminate(SimStruct *S) 
{ 
} 




















#ifdef MATLAB MEX _ FILE /*Is this file being compiled as a MEX-file?*/ 
#include "simulink.c" /*MEX-file interface mechanism*/ 

#else 

#include "cg_sfun.h" /*Code generation registration function*/ 
#endif 
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